Certain prior art approaches may execute some components of a host operating system in a separate isolated peer virtual machine to the virtual machine in which main host operating system resides. The purpose of doing so is to protect various security data structures from ever being accessed by the host operating system kernel lest the host operating system kernel becomes compromised. In some situations, it may be desirable to execute another hypervisor on the host operating system. When a hypervisor is executing within a virtual machine at a lower privilege than another hypervisor, then the lower priority hypervisor is said to be nested.
As is well-known, there are two types of hypervisors, conveniently named Type-1 and Type-2. A Type-1 hypervisor is considered a bare-metal hypervisor and runs directly on top of virtual or physical hardware. A Type-2 hypervisor operates as a component of an existing operating system kernel.
Some hypervisors support nested virtualization, while others do not. To illustrate one problem this poses, it will first be helpful to appreciate how nested virtualization might be performed by considering FIG. 1A, which is a block diagram illustrating a first virtualized environment according to the prior art. FIG. 1 depicts a Type-1 hypervisor 110. Hypervisor 110 executes at the highest privilege (root), and may perform virtualization tasks with the direct assistance of the underlying hardware. Hypervisor 110 may instantiate one or more virtual machines, such as virtual machine 120 and 122. In the parlance of Intel technology, virtual machines 120 and 122 may be implemented as a Virtual Machine Control Structure (VMCS).
Within each virtual machine may execute an operating system, e.g., host operating system 130 may execute in virtual machine 120. Host operating system 130 may itself comprise a Type-2 hypervisor, such as Type-2 hypervisor 140. Hypervisor 140 supports nested virtualization and consequently may instantiate one or more virtual machines, such as virtual machine 150. Within virtual machine 150 may execute operating system 160. In FIG. 1A, hypervisor 110 supports nested virtualization, thereby allowing hypervisor 140 to operate.
Now consider the case where hypervisor 110 does not support nested virtualization, as is the situation depicted in FIG. 1B, which is a block diagram illustrating a second virtualized environment according to the prior art. As depicted in FIG. 1B, if an attempt is made to load Type-2 hypervisor 140 within host operating system 130, then Type-2 hypervisor 140 would try to access the underlying hardware for virtualization support (such hardware support is known as VT-x on Intel systems). However, in the situation depicted in FIG. 1B, Type-2 hypervisor 140 will observe that the (virtual) CPU does not support certain hardware virtualization extensions (as they are currently being used by hypervisor 110), and so hypervisor 140 will be unable to function unless hypervisor 140 supports legacy fallback virtualization capabilities that do not rely upon VT-x hardware virtualization support. As a result, virtual machine 150, and by extension operating system 160, may not be able to be created/loaded by the system of FIG. 1B. Thus, the present art exhibits certain undesirable limitations and restrictions when hypervisors do not support nested virtualization.